Multi-protocol Label Switching is an Internet Engineering Task Force (IETF) initiative that integrates Layer 2 information about network links (bandwidth, latency, utilization) into Layer 3 Internet Protocol (IP) within a particular autonomous system or Internet Service Provider (ISP) to simplify and improve IP-packet exchange.
In an MPLS network, incoming packets are assigned a “label” (identifier) by Label Edge Routers (LERs). These labels not only map to information based on the routing table entry (i.e., destination, bandwidth, delay, and other metrics), but also refer to the IP header field (source IP address), Layer 4 socket number information, and class of service. Once this classification is complete and mapped, different packets are assigned to corresponding Labeled Switch Paths (LSPs).
With these LSPs, network operators can divert and route traffic based on data-stream type and Internet-access customer. MPLS gives network operators a flexibility to divert and route traffic around link failures, congestion, and bottlenecks.
Numerous improvements to MPLS technology and applications of MPLS technology to telecommunications networks have been suggested and tried so far.
The IETF Draft “A Path Protection/Restoration Mechanism for MPLS Networks”, July 2001, by Owens et al http://www.watersprings.org/links/mlr/id/draft-chang-mpls-path-protection-03.txt describes the functioning of a Label Switched Router (LSR) as a vehicle for maintaining classes of service and service restoration for paths between nodes in a network.
Another IETF draft “Extensions to RSVP-TE for MPLS Path Protection”, July 2001, also by Owens et al, http://www.watersprings.org/links/mlr/id/draft-chang-mpls-rsvpte-path-protection-ext-02.txt deals with the signaling systems involved in path set up in an MPLS labeling system. This paper describes objects that have been added to create a label switched path (LSP) tunnel, which for this purpose include RECORD-ROUTE, SESSION-ATTRIBUTE, EXPLICIT-ROUTE, LABEL-REQUEST and LABEL. These processes describe how to set up and manage flows in a data network.
Another IETF Draft, “LSP Hierarchy With MPLS TE” by Kireeti Kompella and Yakov Rekhter, March 2001, introduces the concept of a tunnel by using LSPs within an LSP, in which a traditional label allocation and distribution approach has been used (generally referring to a per platform label space or a per interface label space).
One of the recent IETF drafts that discusses MPLS is RFC 3031 “Multi-protocol Label Switching Architecture” by E. Rosen from Cisco Systems, A. Viswanathan from Force 10 Networks, Inc., and R. Callon from Juniper Networks, Inc., dated January 2001, which includes the discussion of the label space (Section 3.14 Scope and Uniqueness of Labels). The document discusses the traditional per-platform and per-interface label space, and it also mentions multiple per interface or multiple per platform label spaces. This document states that the “level” of the label is irrelevant and that there is no notion of different label spaces for different labels in the hierarchy.
Unfortunately, the above mentioned approaches for label allocation in MPLS networks have drawbacks and may cause label collision in certain protection schemes, e.g. during tunnel Forwarding Adjacency (FA)-LSP protection. They are also not suitable for expeditious handling of data flows having complex structure.
Accordingly, there is a need in industry for the development of an improved approach for allocating and controlling labels in an MPLS network, which would avoid the above-mentioned problems, while being simple and efficient.